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SECTION 1 

EXECUTIVE SUMMARY 


The Data Distribution Satellite System (DDSS) described in this report will be capable of providing the 
space research community with inexpensive and easy access to space payloads and space data. 
Furthermore, the DDSS is shown to be a natural outgrowth of advances and evolution in both NASA’s 
Space Network and in commercial satellite communications. The roadmap and timescale for this evolution 
is described in this report along with key demonstrations, proof-of-concept models, and required 
technology development that will support the projected system evolution toward the DDSS. 
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1.1 STUDY GOALS 

The key goals of this study are outlined in Exhibit 1-1. The first goal is to define how a DDSS, in 
concert with the follow on to Advanced TDRSS, an Advanced Space Data Acquisition and 
Communications System (ASDACS), can support NASAs space communication requirements in three 
areas. These areas are: 

• Direct distribution of space data 

• Easy and interactive communications with space payloads 

• Networking among the community of space scientists and major processing and archiving facilities. 

The DDSS and ASDACS are assumed to be products of a natural evolution in NASA’s Space Netwoik 
(SN). Thus, the second important goal of the study is to show how the orderly transition from ATDRSS 
to the ASDACS/DDSS may be accomplished. The current plan is for the ATDRSS lifetime to extend 
from 1997 to 2012 which thus defines the applicable timeframe for the transition activities. Finally, the 
third study goal is to develop and describe key demonstrations and proof-of-concept models that will serve 
as an R&D basis for establishing achievable ASDACS/DDSS performance goals and designs. 


1-2 


R91023.1 


• DEFINE A DATA DISTRIBUTION SATELLITE SYSTEM (DDSS) AND AN 
ADVANCED SPACE DATA ACQUISITION AND COMMUNICATIONS SYSTEM 
(ASDACS) THAT SUPPORT THE YEAR 2010 SCENARIO FOR 

- DIRECT SPACE DATA DISTRIBUTION TO PRINCIPAL AND OTHER 
INVESTIGATORS 

- INEXPENSIVE, USER FRIENDLY AND INTERACTIVE 
COMMUNICATIONS WITH SPACE PAYLOADS 

- NETWORKING AMONG SPACE SCIENCE PEER INVESTIGATORS AND 
MAJOR PROCESSING AND ARCHIVING FACILITIES 

• DEFINE THE STEPS THAT MUST BE TAKEN TO PROMOTE AN ORDERLY 
TRANSITION TO THE DDSS AND ASDACS ARCHITECTURE 

• DESCRIBE PROOF OF CONCEPT MODELS THAT WILL DEMONSTRATE 
IMPORTANT FUNCTIONAL AND PERFORMANCE CAPABILITIES OF THE 
CRITICAL TECHNOLOGIES THAT SUPPORT THE DDSS 


Exhibit 1-1: Data Distribution Satellite System Study Goals 
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1.2 DDSS TIMEFRAME 

Exhibit 1-2 illustrates the 25 year time period from 1990 to 2015, in which TDRSS is replaced by 
ATDRSS, and ATDRSS gives way to the ASDACS/DDSS. Since ATDRSS is planned to last out to 2012 , 
the time frame for an operational DDSS begins as early as 2010. However, to ensure an orderly transition 
from ATDRSS, a number of DDSS-related activities are appropriate much earlier in the ATDRSS time 
frame. These include the initiation of a demonstration DDSS as early as 2005, as well as more limited 
ground and flight demonstrations beginning in 1995. Proof-of-Concept (POC) model development could 
begin as early as 1992. 

The planned Future Service Growth (FSG) capability of the ATDRSS is of particular importance in such 
demonstrations. The FSG is an allocation of ATDRSS real estate, mass and power for a payload that will 
support evolution and growth in ATDRSS services. As will be shown in this study, the FSG can play a 
pivital role in the transition from the ATDRSS to the ASDACS timeframe. This transition could consist 
of 3 stages as follows: 

• In the first stage starting in 1997, the FSG could be used to demonstrate a new ATDRSS capability 
as a prelude to a second operational stage. 

• In the second operational stage starting about 2000, the FSG payload will support the new ATDRSS 
capability as part of normal operations. 

• Finally, in the third stage starting as early as 2005, a demonstration DDSS satellite could be 
launched and provide much expanded capabilities and services. Here too, the FSG would play a 
key role such as providing the interface for linking an ATDRS* with the demonstration satellite via 
an intersatellite link. 

With all three stages initiated, the path would be paved for complete transition to the operational 
ASDACS/DDSS architecture because, both the spacecraft technology and operational aspects would have 
been thoroughly explored. 


ATDRSS - The system. 

ATDRS - A single relay satellite of the system. 
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on from TDRSS to ATDRSS and Beyond 
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1.3 DDSS STUDY WORK FLOW 

Exhibit 1-3 illustrates the work flow for this study. The projected requirements for the DDSS are 
developed at the outset from key NASA documents and studies. These include the most recent ATDRSS 
Mission Model as well as planning documents for data handling and distribution in the various science 
disciplines. The chief driver in this latter arena is the earth science area embodied in the Earth 
Observation System (EoS). 

The developed requirements form the basis for parallel efforts aimed at exploring the DDSS operations 
concept and system architecture. The operations concept is strongly influenced by ATDRSS heritage as 
well as evolving concepts for advanced commercial satellite communications. In die system architecture 
definition, two alternative classes of architectures are explored: one where ASDACS and DDSS functions 
are integrated into the same spacecraft, and one where the ASDACS and DDSS functions are allocated 
to distinct spacecraft. 

The work on operations concept and system architecture then flows into system definition. In this area, 
the major performance envelopes of the ASDACS, DDSS, and the user community are derived and 
reference implementations are developed. The culmination of this work is the definition of a climax 
DDSS and ASDACS system that meets all of the projected requirements developed at the outset. These 
results then feed back into requirements to determine the sensitivity of the DDSS design to modest 
changes in the initial requirements. This iteration is important for defining a demonstration DDS to 
support the smooth transition from ATDRSS to the ASDACS/DDSS. The output of transition 
considerations is a roadmap for system evolution versus time which includes the definition of key 
demonstration objectives and milestones for POC models, flight demonstrations, and a demonstration Data 
Distribution Satellite. 
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1.4 KEY STUDY RESULTS AND CONCLUSIONS 
The key outputs of this DDSS study are: 

• The identification of baseline communications requirements for direct distribution of space data, 
interactive space operations, and networking. 

• The definition and evaluation of two alternative DDSS/ASDACS architectures and their 
corresponding communications payloads. 

- CONUS Gateway Architecture 

- Global Network Architecture 

• A description of scenarios for orderly transition from ATDRSS to the CONUS Gateway architecture 

• Descriptions of demonstrations and Proof-of-Concept (POC) models supporting DDS development 
and transition to the CONUS Gateway architecture 

• Definition of a demonstration DDS applicable to the ATDRSS timeframe 
1 . 4.1 Requirements 

Exhibit 1-4 summarizes the potential system requirements for communications with orbiting space 
platforms, and for networking of NASA’s Major Facilities and Bid Users of space data. Key features 
of the projected requirements are a high data throughput rate. The chief driver for this is the 4 Gbps 
throughput for networking Major Facilities (archives, processing centers, and supercomputer centers) and 
End Users (users of space data not in major facilities; interface is assumed to be via VSATs). The 4 Gbps 
is made up of dozens of high data rate two-way channels (£ or 50 Mbps) connecting major facilities and 
perhaps thousands of lower data rate one-way channels (-1 Mbps) from Major Facilities to End Users. 
The networking throughput also incorporates thousands of low data rate connections (16-128 Kbps) 
between thousands of End Users for data, voice, and videoconferencing. The other major driver for 
system throughput is the return space data channels. ATDRSS will provide as many as 8 single access 
channels that support high data rate return services at up to 650 Mbps. The 2 Gbps peak throughput 
projected for return space data is consistent with the simultaneous use of as many as 3 return channels at 
650 Mbps or 6 channels at 300 Mbps. 
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RELAY FOR SPACE DATA: NETWORKING OF GROUND ELEMENTS: 


• 2 Gbps RTN DATA THROUGHPUT • 4 Gbps DATA THROUGHPUT 

• 100 Mbps FWD THROUGHPUT • DOZENS OF HIGH DATA RATE CHANNELS 

• HIGH DATA RATE DEDICATED CHANNELS (>50 Mbps) BETWEEN MAJOR FACILITIES 

• LOW DATA RATE SHARED CHANNELS * THOUSANDS OF ~ 1 Mbps CHANNELS 

• PACKET SWITCHED SERVICE FROM MAJOR FACILITY TO END USERS 
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1.4.2 Alternative Architectures 

Exhibit 1-5 illustrates the two alternative classes of ASDACS/DDSS architectures explored in this study. 
The CONUS Gateway Architecture assumes separate DDS and ASDACS satellites that are "connected" 
via RF or optical crosslinks. The DDS would be placed directly over CONUS and the two ASDACS 
relays would be positioned at locations with wider separations than the E and W locations envisioned for 
ATDRSS. In this manner, the CONUS Gateway Architecture would eliminate the zone of exclusion 
(ZOE). In the Global Network Architecture, die ASDACS and DDS functions are integrated into a 
common satellite. The Global Network constellation would be made up of 2-4 such satellites connected 
via crosslinks. Placement of the satellites would be such as to eliminate the ATDRSS ZOE and to 
provide a Global Network connecting major facilities and end users located in all key nations active in 
space. 

For both the CONUS Gateway and Global Network Architectures, communications payloads were defined 
that meet the projected system requirements. The payloads were described at the block diagram level for 
major components, and weight and power estimates were generated with the components indentified in 
the diagrams serving as the starting point While both payloads were large, the payload for the Global 
Network Architecture was especially so, given that it must support the functionality of both the ASDACS 
and the DDS. The Global Network Architecture also involves significantly more operational complexity 
and uncertainty because it is essentially an international system providing service to all nations active in 
space. Finally, the Global Network Architecture does not lend itself to a transition from ATDRSS For 
these reasons, only the CONUS Gateway Architecture was chosen for complete description. 
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1.4.3 Transition Issues 

The transition from the ATDRSS to the CONUS Gateway Architecture involves the major changes in a 
number of areas. These include: 

• Changeover to a new system architecture and orbital constellation 

• The development of new communications payloads and satellites 

• The insertion of new technologies into the communicationspayloads 

• The introduction of new operations concepts concerning service provision, assurance and scheduling 

The baseline ATDRSS is comprised of four operational satellites which all have line-of-sight to the 
ATDRSS ground terminals at the White Sands complex as indicated in Exhibit 1-6. In this architecture, 
all SGL connections to the satellites are via the White Sands complex. In contrast, in the CONUS 
Gateway architecture there are many SGL connections to the Major Facilities and thou sa nds of connections 
to VSATs widely distributed over CONUS. Furthermore, neither of the ASDACS satellites have line of 
sight to White Sands, but are instead connected to White Sands and other CONUS locations via crosslinks. 

With the introduction of so many new features, it will be important to plan the transition so that the new 
features can be demonstrated prior to operations, and these features can be introduced in a gradual manner. 
Exhibit 1-6 illustrates potential route for the transition of NASA’s space network from TDRSS, through 
ATDRSS, and finally to the DDSS/ASDACS system. Within this timeline, it is seen that the ATDRSS 
Future Service Growth (FSG) module [12] can play a key role in supporting an orderly transition from 
the ATDRSS to its follow-on (i.e. the DDSS CONUS Gateway architecture). The ATDRSS/FSG is a 
reserved allocation of spacecraft resources (weight, power, size, view angles) that will host a payload yet 
to be defined. The objective of the FSG is to support a modest growth in the services offered by 
ATDRSS. Possible payload options under consideration include a crosslink capability as well as a direct 
data distribution capability. 

The opportunities for the first flight demonstrations utilizing the ATDRSS/FSG will occur from the late 
1990’s to the early 2000’s. If successful, similar payloads on the FSG will support service enhancements 
throughout the ATDRSS era, from the early 2000’s to beyond 2010. Finally, starting about 2005, the 
launch of a demonstration satellite with most of the capabilities of the DDS in the CONUS Gateway 
architecture would be feasible. Each of these activities are phased such that the preceding activity 
supports the definition of the follow-on. Thus, successful demonstration of an FSG capability leads to 
operational support of that capability. This operational capability can then be greatly enhanced by the 
introduction of the demonstration DDS which in concert with a crosslink to the ATDRSS/FSG, can close 
the ATDRSS coverage zone of exclusion and offer direct data distribution services. Finally, the 
demonstration DDS supports a gradual transition to the DDSS/ASDACS climax architecture as is shown 
in Exhibit 1-6. 
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Exhibit 1-6: Potential Route for ATDRSS/FSG Evolution to ASDACS/FSG 

Conus Gateway Architecture 
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1.4.4 Demonstration DPS Description 

The primary rationale for the demonstration Data Distribution Satellite is to support the smooth transition 
to the climax CONUS Gateway architecture in the ATDRSS timeframe. With the proper payload on the 
ATDRSS/FSG to support the interface with the DDS, all the key operational capabilities of the climax 
CONUS Gateway architecture can be demonstrated and instituted in the ATDRSS timeframe. These 
capabilities include: 

• Direct distribution of space data to Major Facilities and End User VSATs. 

• Interactive operations of space payloads from VSATs. 

• Wideband networking among all major facilities. 

• Wideband access to Major Facilities from VSATs for data retrieval and supercomputer access. 

Exhibit 1-7 summarizes the key target requirements of the demonstration DDS payload and illustrates the 
various payload components, nie envelope capacity for space data distribution is roughly 1.2 Gbps which 
is large enough to support at least one ultra-high data rate channel from each ATDRS. In addition, a 
networking capacity of up to 2 Gbps between Major Facilities is provided. The subsystems of the 
proposed demonstration DDS are follows: 


• The SGL Subsystem: this contains a high gain transmitter, a high gain receiver, and a CONUS 
coverage receiver/transmitter. 

- The high gain transmitter implementation is a Ka-band phased array feed antenna with 8 
hopping 0.3° beams that can scan all of CONUS. The power of each beam is between 2 and 
20 watts, adaptive to rain degradation. The data rate supported by each beam is 300 Mbps 
to Major Facilities and 150 Mbps (rate 1/2 coded) to End User VSATs. Higher data rates 
to major facilities are supported via assignment of multiple beams. 

- The high gain receiver is also at Ka-band and supports ten fixed 0.3° beams distributed over 
CONUS so as to provide coverage to all Major Facilities. Each beam supports 300 Mbps. 

- The CONUS receiver^transmitter provides a shaped duplex beam at Ku-band covering all of 
CONUS. The transmit end supports a 1 Mbps TDM downlink for space data, and the receive 
end supports one or more 100 Kbps uplink random access channels. 

• The Processing and Routing Subsystem: this includes a CCSDS processing capability for space data, 
and additional processing capability for the switching and routing of networking data. 

• The Crosslink Subsystem: this includes die modems and codec for the ATDRSS space-space 
channels, and the two optical terminals that support the links to the two ATDRS. 
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DEMONSTRATION DPS COMMUNICATIONS PAYLOAD DRIVERS 


Constraints: must be compatible with the crosslink interface of the ATDRSS/FSG - assume optical crosslink interface 
Objectives: validate and support ATDRSS transition/evolution toward the CONUS Gateway architecture 
Applicable timeframe: 2005 or shortly thereafter 
Target requirements: 

— Direct distribution of return space data 

♦ - 1-2 GBPS total capacity to Major Facilities 

♦ - 1 MBPS total capacity to End Users 

♦ on-board CCSDS packet processing & switching 

- Direct link for forward space data 

a - 100 MBPS capacity from Major Facilities 

♦ ; 100 KBPS capacity from End Users 

♦ CCSDS packet processing & switching 

- Two crosslinks (up to 80* Geo are) with ATDRSS/FSG 

♦ - 600 MBPS receive data rate 

♦ 100 MBPS transmit data rate 

♦ On-board modems/codecs for space -space channel! 

— Networking of ground elements (e.g., Supercomputer highway) 

♦ -2 GBPS total capacity between Major Facilities (300 MBPS links) 

♦ 150 MBPS links from Major Facilities to selected End Users. 



Exhibit 1-7: Demonstration DDS Communications Payload Drivers 
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The demonstration DDS, in conjunction with ATDRSS constitute an interesting hybrid architecture in 
which one pair of ATDRS stationed at 41° and 171° West are supported directly via White Sands and a 
second pair are supported via die DDS. Exhibit 1-8 illustrates the segment of the system supported by 
the DDS. The system architecture and operations of the other two ATDRS are unchanged from the 
ATDRSS baseline. The DDS-supported ATDRS are provided flexible high data rate connectivity to many 
Major Facilities, and a 1 Mbps broadcast capability to 1000s of End User VSATs. Exhibit 1-8 also 
illustrates an artists concept of the DDS which clearly shows the transmit and receive multi-beam 
antennas, the optical crosslink terminals, and the CONUS coverage antenna. 
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SYSTEM ARCHITECTURE INCORPORATING A DEMONSTRATION DDSS 

TWO OF FOUR ATDRS ARE CONNECTED TO GTs Via The DDS 


Demonstration DDS 
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1.45 Mass/Power/Cost Estimates 

The table in Exhibit 1 -9 summarizes the mass and power estimates for the communications payload of the 
demonstration DDS. The sources of the data base used to generate the estimates encompass numerous 
payload studies for ATDRSS and several other studies of advanced communications payloads. The bottom 
line payload figures of 980 lbs. and 1669 watts are well within the envelope of currently considered 
payloads for communications satellites. With respect to the satellite bus, the 5000 series bus of General 
Electric can probably support a total mass of somewhat more than 6000 lbs. at liftoff and a total power 
of 3 KW at end of life. The mass envelope is roughly consistent with the following DDS mass 
requirements for the spacecraft, stationkeeping fuel, and apogee kick motor (AKM): 

• Spacecraft dry weight: 2584 lbs 

• Stationkeeping fuel (10 years): 600 lbs 

• AKM (partially loaded Thiokol Star 488-17): 3200 lbs 

Thus the total weight estimate at liftoff is about 6500 lbs. This is clearly compatible with either an Atlas 
IIAS/Centaur launch or a Titan III launch. It is worth noting that it only slightly exceeds the launch 
capability for an Atlas IIA/Centaur. 

Exhibit 1-8 also summarizes the cost estimates for the demonstration DDS. The payload and spacecraft 
bus costs were generated using the USCM6 cost model. The outputs are in 1986 dollars. The launch cost 
cited is based upon 1990 data and is in 1990 dollars. As expected, the cost of any new one-of-a-kind 
spacecraft is considerable. However, over half of the cost is attributed to non-recurring payload costs. 
If a significant technology development program is mounted throughout the 90’s in support of DDS-like 
payload capabilities, the actual non-recurring cost is expected to be much less. Furthermore, any DDS 
program purchasing multiple copies will reap the significant unit cost reduction by spreading the 
non-recurring costs over the spacecraft copies. Learning curve phenomena will also promote cost 
reduction. The unit costs for 2 spacecraft and 10 spacecraft are tabulated in Exhibit 1-9 and are believed 
to represent reasonable upper and lower unit cost bounds. In summation, the cost of a demonstration DDS 
is expected to be in the range of 250 million to 500 million dollars. 
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SYSTEM ELEMENTS 

WEIGHT (LBS) 

POWER 

(WATTS) 

HIGH GAIN RCV 3GL 

180 

125 

HIGH GAIN XMIT SGL 

272 

738 

DUPLEX CONUS SGL 

50 

126 

SWITCHING AND ROUTING 

80 

360 

CROSSLINK TERMINALS 

102 (X2) 

90(X2) 

PROCESSING OF SPACE- 
SPACE CHANNELS 

112 

140 

TOTAL 

980 

1669 

PAYLOAD 

(W/- 10 % REDUNDANCY ALLOWANCE) 


SPACECRAFT 
(GB 500 SERIES BUS) 

2584 LBS (DRY WEIGHT) 

3 KW (EOL) 


• COST FOR BUY OF 1 S/C: 


USCM6 COST MODEL (86$) 



NON-RECURRING 


S/C 670 M$ 

(- 80% P/L) 
(- 20% BUS) 


LAUNCH” 


LOWER BOUND UNIT COST: 254.8 M$ 

- 10 S/C BUY 

- 80% LEARNING CURVE 

UPPER BOUND UNIT COST: 530.6 M$ 

- -2 S/C BUY 

- 80% LEARNING CURVE 


RECURRING" 


240 M$ 

(- 70% P/L) 
(- 30% BUS) 


- 100 M$ 


TOTAL 


910 M$ 


- 100 M$ 
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SECTION 2 

DDSS REQUIREMENTS DEFINITION 


The requirements for the DDSS incorporate the areas of direct distribution of space data, interactive space 
operations, and networking. This section describes the approach toward developing requirements in these 
categories and discusses the resulting requirements envelopes. 
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2.1 APPROACH TO REQUIREMENTS DEFINITION 

In developing long term requirements projections out to 2010, it is important to base requirements on 
broad trends rather than specific details. In this way, the requirements developed are robust in that they 
do not depend strongly on detailed user characteristics and mission scenarios. This approach is also 
necessitated by the fact that detailed user descriptions and mission scenarios applicable to 20 years down 
the road are typically not available. 

Exhibit 2-1 illustrates the approach taken toward requirements definition. The basis for all requirements 
identified for the DDSS are NASA documents and studies including the following: 

• The ATDRSS Mission Model [1] 

• The Customer Data and Operations System (CDOS). 

- Project Management Plan [2] 

- Level I and II Requirements [3, 4] 

- Concept Definition [5] 

- Operations Concept [6] 

• EoSDIS 

- Baseline Report [7] 

- Data Transfer and Data Communications Requirements Study [8] 

• Information System Scenarios for Space Science and Applications [9] 

• Space Station Information System (SSIS) [10] 

These and other documents were used to characterize users of the DDSS and project their requirements. 
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Exhibit 2—1: Generic Approach to Requirements Definition 
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22 DESCRIPTION OF REQUIREMENTS 

Exhibit 2-2 illustrates the projected view of NAS As Space Network beyond the year 2010. The 
communications infrastructure of the network is composed of the ASDACS (the follow-on to ATDRSS) 
and the DDSS, the Space Network Control (SNC), and the data distribution elements of CDOS and 
NASCOM. The users of the Network fall into three categories. These are: 

• Orbiting Space and Other Airborne Platforms 

• Major Facilities 

— Science Data Handling Centers (SDHCs): Science Data Processing and Super Computing 

- Science Data Archives (SDAs): Provides data storage and access to archives 

- Science Operations Centers (SOCs): Controls science instruments and plans the science 

mission activities 

- Platform Operations Centers (POCs): Controls the orbiting space platforms and plans 
platform activities 

• End Users: Individual investigators and other non-institutional DDSS users 

While Space Platforms and Major Facilities are relatively few in number (i.e., dozens), the number of End 
Users is quite large, and they are widely distributed. Also, since one of the goals is to provide low cost 
and friendly access to space data, the End User communications capability is assumed to be consistent 
with that of Very Small Aperture Terminals (VSATs) for satellite communications. 
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Exhibit 2—2: Simplified View of the Space Network and Users Beyond 2010 
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DDSS user requirements have been grouped into three categories. These are as follows: 

• Direct distribution of platform data to data processing/archiving facilities and end users 

- Support rapid and efficient access to space data 

- Platform data storage dumps 

- Real-time science and engineering data 

• Interactive operation of space platforms and instruments 

- Support demand access in real-time 

- Platform command uploads and acknowledgement 

- Telescience, telerobotics and teleoperations 

- Ground-crew interactions via voice and video 

• Networking of the community of facilities and end users involved in space science and space 
operations 

- Peer networking among end users 

- Major Facility connections 

— End Users access to major facilities (e.g., archives and super computing facilities). 

The requirements of each of these categories is discussed below. Each category is characterized by a 
figure showing the required connectivity, the number of required channels and their data rates, and a traffic 
description. 

Exhibit 2-3 illustrates a representative user set and peak load requirement for direct distribution of space 
data. The point of origin the data (specific Orbiting Platforms) are listed, along with the ultimate data 
destinations at Major Facilities and End Users. This information in this table is based primarily upon the 
ATDRSS Mission Model for 2010 and the capabilities projected for ATDRSS [1], The ATDRSS will 
provide up to eight single access (SA) channels each capable of supporting up to 650 Mbps, and up to 
20 multiple access (MA) channels, each at up to 50 Kbps. The total data rate envelope for the projected 
missions in 2010 is 529 Mbps. However, because the ATDRSS SA service will be able to provide up to 
650 Mbps, a sizable requirements growth is expected. We have chosen here a 2 Gbps maximum envelope 
for data distribution which is approximately equivalent to 3 simultaneous SA channels operating at 650 
Mbps. 
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Exhibit 2—3: ASDACS/DDSS User Busy Day Peak Load Requirements for Direct Data Distribution 
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Exhibit 2-4 further illustrates the data distribution requirement for the DDSS. The figure shows that direct 
data distribution requires return connectivity from Orbiting Platforms to selected Major Facilities and End 
Users. While the Major Facilities are few in number and clustered in about 10 locations, the End Users 
(which include all astrophysical and earth scientists that use data generated in space) num ber in the 1000’s 
and are widely distributed over CONUS. Much of the data traffic, particularly to Major Facilities will be 
sent in long continuous streams, but a significant portion of data traffic to End Users will be bursty in 
nature. 
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ORBITING PLATFORMS 


ASDACS/DDSS 


HIGH DATA 
RATE STREAMS 


sDHCs, SDAs\ 

SOCs AND J * 

POCs ^ 

~ 30 SDHCs 
AT ROUGHLY 10 
DISTRIBUTED CONUS 
LOCATIONS 


LOW DATA 
RATE 
STREAMS 





Traffic Description 


TYPICAL APPLICATIONS 

- LARGE FILE TRANSFER OF STORED SCIENCE AND ENGINEERING DATA (I.E., 
MEMORY DUMP) 

- REAL-TIME OUTPUT FROM ONE OR MORE INSTRUMENTS 

WIDE RANGE OF DATA RATES 

- ULTRA HIGH DATA RATES: 50 Mbps TO 650 Mbps 

- HIGH DATA RATES: 3 Mbps TO 50 Mbps 

- MODERATE DATA RATES: 128 Kbps TO 3 Mbps 

- LOW DATA RATES: <, 128 Kbps 

CONTINUOUS TO A FEW GROUND TERMINALS (E.G.. HIGH DATA RATE STREAMS TO 
MAJOR FACILITIES) 

BURSTY UTILIZATION TO MANY END USERS (E.G., READOUTS FROM A SINGLE SENSOR 
MAY OFTEN BE BURSTY) 

REQUIREMENTS FOR PRIOR SCHEDULING TO SERVICE SOME MISSIONS (E.G., HST OPS 
ARE PREPLANNED WELL IN ADVANCE) 

REQUIREMENTS FOR STORE/DUMP MODE OF OPS vs REAL TIME (E.G., HST FINE 
POINTING NOT POSSIBLE WITH SLEWING COMM ANTENNA) 
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Exhibit 2-5 illustrates the DDSS requirement for interactive space operations. Interactive operations 
require two-way links supporting forward and return services. This requirement could be served via a 
dedicated two-way link, but typically, the bursty nature of traffic in at least one direction raises the 
possibility of rapidly configured time-shared links to simulate a continuous two-way connection. 
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TYPICAL APPLICATIONS 

- UPLOADS OF COMMAND SCHEDULE AND OTHER LARGE FILES 

- GROUND/CREW INTERACTIONS 

- PAYLOAD OR PLATFORM INTERACTIVE CONTROL 

- MESSAGE TRANSACTIONS 

ASYMMETRY BETWEEN FORWARD AND RETURN LINKS 

- FILE UPLOADS: CONTINUOUS FORWARD, BURSTY RETURN 

- PAYLOAD INTERACTIVE CONTROL: MAY BE BURSTY FORWARD AND 
CONTINUOUS RETURN OR BURSTY IN BOTH DIRECTIONS 

FORWARD DATA RATES 

- 125 bps TO 100 Kbps FOR UNMANNED PLATFORMS 

- 216 Kbps TO 50 Mbps FOR MANNED MISSIONS: VIDEO IS THE PRIMARY DRIVER 
FOR THE HIGHER DATA RATES 

INTERACTIVE RETURN DATA RATES 

- VIDEO REQUIREMENTS AT DIFFERENT LEVELS OF QUALITY (1 Mbps - 100 Mbps) 
ARE THE PRIMARY DRIVER FOR CONTINUOUS Mbps DATA RATES 

- MUCH TELESCIENCE ACCOMMODATED BY 4 Kbps - 1 Mbps BURSTS 

A LINK SUPPORTING INTERACTIVE OPERATIONS MAY BE IN AN "EMBEDDED" OR 

"STAND-ALONE" ENVIRONMENT 

- EMBEDDED: INTERACTIVE TRANSACTIONS EMBEDDED IN A CONTINUOUS 
DUPLEX LINK SERVING A NUMBER AND VARIETY OF DATA TRANSFERS 

- STAND-ALONE: LINK SERVES A SINGLE INTERACTIVE OPERATION AND IS 
ESTABLISHED INTERMITTENTLY ACCORDING TO THE NEEDS OF THE 
TRANSACTION 


Exhibit 2-5: Interactive Operation of Space Platforms and Instruments 
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Exhibit 2-6 illustrates the DDSS requirement for networking among Major Facilities and End Users. It 
is important to note that such networking is the biggest driver for DDSS throughput. By far, the discipline 
where the most data will be generated and processed is earth science. The entries in the table of Exhibit 
2-6 are consistent with the continuous generation of about a 100 Mbps of data in space, and about a factor 
of 10 multiplier for providing the network to support the subsequent processing, reprocessing and archive 
storage/retrieval envisioned. This factor of 10 multiplier is traceable to the EoS DIS Data Transfer and 
Data Communications Requirements Study [8]. 
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Traffic Description 

• TYPICAL APPLICATIONS 

- MAJOR FACILITY - MAJOR FACILITY CONNECTION 

- MAJOR FACILITY - END USER CONNECTIONS 

- END USER - END USER CONNECTION 

• MAJOR FACILITY - MAJOR FACILITY 

- HIGH DUTY CYCLE (UP TO 100%) HIGH DATA RATE LINKS FOR ARCHIVING AND ARCHIVE RETRIEVAL, 
AND LINKAGE OF ARCHIVES AND SUPERCOMPUTERS: 

♦ T1 TYPICAL FOR ASTROPHYSICS 

♦ T3 AND HIGHER FOR EARTH SCIENCE 

- MESSAGE, VOICE. AND VIDEO CONFERENCE SERVICES 

• MAJOR FACILITY - END USER 

- LOW DUTY CYCLE 1 HR/DAY) T1 AND GREATER; OFTEN BURSTY UTILIZATION; LINKS FROM MAJOR 
FACILITY TO END USER FOR ARCHIVE RETRIEVAL AND SUPERCOMPUTER ACCESS 

- MESSAGE. VOICE AND VIDEO CONFERENCE SERVICES; SUPERCOMPUTER HIGHWAY TO END USERS 

• END USER - END USER 

- LOW DUTY CYCLE (S 2 HR/DAY) BASIC ISDN SERVICE, OFTEN BURSTY UTILIZATION 


- MESSAGE, VOICE AND VIDEO CONFERENCE SERVICES 





• EOS— DIS PLANWNG DOCUMENTS ARE THE DRIVER 


•* REASONABLE ESTIMATES 


Exhibit 2-6: Networking of Major Facilities and End Users 
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23 DDSS USER REQUIREMENTS SUMMARY 

Exhibit 2-7 summarizes the total envelope of ASDACS/DDSS system requirements. The function of the 
ASDACS/DDSS combination system is to provide the following connectivities: 

• Return links between Orbiting Platforms and ground users (Major Facilities and End User VS ATs). 

• Interactive links between Orbiting Platforms and ground users. 

• Two-way links between the community of all Major Facilities and End Users. 

These connectivities and the traffic required on the connections are the drivers for establishing the system 
requirements for ASDACS space-space links, DDSS throughput and DDSS space ground links. The key 
features in each of these areas are as follows. 


• Space-space links connecting orbiting platforms with the ASDACS: The wide arrows represent 
TOR and UHDR links while the single line arrows represent the MDR and LDR links. Based upon 
the heritage of the planned ATDRSS architecture, there are 8 HDR/UTOR links and 20 MDR/LDR 
links. 

• DDSS data throughput: The primary drivers for data throughput are networking of ground users, 
and return space data distribution. These account for 4 Gbps and 2 Gbps respectively, for a total 
peak processing envelope of up to 6 Gbps. 

• Space-ground links connecting the DDSS with Major Facility and End User terminals. These links 
again are grouped into TOR/UTOR categories and MDR/LDR categories. Typically, the 
HDR/UTOR links will be with Major Facility terminals, and the MDR/LDR links will be with End 
User VSAT terminals. 
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SECTION 3 

DDSS OPERATIONS CONCEPT 


The DDSS operations concept describes how the communications infrastructure in NASA’s space network 
will support tiie demanded services. A system’s operations concept is typically evolutionary in nature as 
institutions and their functions adjust to technology insertion and demands for new services over time. 
The major shaping factors of the DDSS operations concept are the combined heritage of ATDRSS and 
space network operations out to 2010, and evolving commercial satcom architectures for small (VSATs) 
and medium-sized earth terminals. This section describes some of the features of the projected evolution 
in operations and services that will influence the definition of the DDSS. 
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3.1 EVOLUTION OF NASA’S SPACE NETWORK 

Exhibit 3-1 illustrates a likely evolution of NASA’s space network. At the current time, NASCOM is the 
chief intermediary providing data distribution services. The service provided is only low-level insofar as 
it provides a trunking capacity between the TDRSS and major facilities. Furthermore, no service at all 
is provided directly to End Users. End User access to data is only via links with Major Facilities. With 
the implementation of CDOS by the year 2000, the combined NASCOM/CDOS infrastructure will provide 
higher level services such as the generation and distribution of standard data products to Major Facilities. 
Limited direct data distribution to End Users may also be provided. By the year 2010, however, with the 
introduction of the DDSS, the combined NASCOM/CDOS/DDSS infrastructure will provide high-level 
services to both Major Facilities and End Users. 
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Exhibit 3—1: Evolution of NASA’s Space Network to the Year 2010 



R91Q23.3 


3.2 FUNCTIONAL ALLOCATIONS AND INTERFACES 

Exhibit 3-2 illustrates the philosophy behind the functional allocation and interfaces of the combined 
DDSS/ASDACS. 

The ASDACS serves the interface with Orbiting Platforms. Given the constrained resource environment 
for Orbiting Platforms, the ASDACS communication payload is assumed to provide a unique and flexible 
interface (such as standards developed by the Consultative Committee on Space Data Systems (CCSDS)) 
[11] to this user community in order to avoid placing needless constraints on these platforms and nurture 
maximum flexibility. In addition, this interface would embody a strong heritage of the previous ATDRSS 
system. 

The DDSS serves the interface to earth terminals of Major Facilities and End Users. For maximum cost- 
effectiveness, these interfaces are assumed to be an evolution of standard commercial interfaces. Thus, 
a key function of the DDSS is to mediate between the unique interfaces with Orbiting Platforms supported 
by ASDACS, and the standard commercial interfaces with earth terminals supported by the DDSS. Thus, 
an End User with a standard commercial VSAT terminal of the future would have direct access to space 
data and payloads via such a terminal. 
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/DRBinN 
SPACE 
SPLAT' “>RMS 


v UNIQUE^ 
INTERFACES 
FOR SPACE 
PLATFORMS 


c 


ASDACS 


UNIQUE AND STANDARD 
COMMERCIAL INTERFACES 
AS APPROPRIATE 



MAJOR 


FACILITIES 


STANDARD COMMERCIAL 
INTERFACES 


ORBITING PLATFORMS 

—UTILIZE CCSDS— LIKE STANDARDS AND PROTOCOLS 
-UTILIZE UNIQUE MODULATION/CODING SCHEMES OPTIMIZED 
FOR THE SPACE COMMUNICATIONS ENVIRONMENT 

ASDACS 

-PROVIDES THE DIRECT LINK WITH ORBITING PLATFORMS 
-BENT PIPE RELAY BETWEEN PLATFORMS AND DDSS; ANY 
ON-BOARD PROCESSING IS ASSIGNED TO THE DDSS 
AS AN ASDACS PAYLOAD 


• DDSS 

-RELAY BETWEEN ASDACS AND GROUND DESTINATIONS, AND 
BETWEEN GROUND USERS 

-PERFORMS MUX/DEMUX, SWITCHING AND ROUTING FUNCTIONS 
INCLUDING BASEBAND PROCESSING WHERE REQUIRED 
-PERFORMS THE CONVERSION BETWEEN CCSDS AND COMMERCIAL 
STANDARDS AS REQUIRED 

• MAJOR FACILITIES: UTILIZE LARGE EARTH TERMINALS AND OTHER EQUIPMENT 
CONFORMING TO CCSDS AND/OR COMMERCIAL STANDARDS FOR DATA TRANSFER 

• END USER UTILIZE SMALL EARTH TERMINALS AND OTHER EQUIPMENT 
CONFORMING TO COMMERCIAL STANDARDS FOR DATA TRANSFER 
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Exhibit 3-3 illustrates the logical evolution of functions within NASA’s Space Network between the years 
2000 and 2010. Five groups of functions are shown in the middle column of the exhibit and assignments 
of these functions between the two target years are indicated. 

The first group of functions performed by Orbiting Platforms are expected to undergo little migration. 
Similarly for the second group of functions performed by ATDRSS in 2000 and by ASDACS/DDSS in 
2010. In contrast, significant migration is expected in third and fourth group of functions allocated to the 
CDOS in 2000. The two cornerstones of CDOS will be the Data Interface Facility (DIF) and the Data 
Handling Center (DHC). The DHC functions are made necessary primarily by the absence of a random 
access storage medium for Orbiting Platforms in the year 2000. By the year 2010, new technology (such 
as optical read/write disks) will enable Orbiting Platforms to do data management and sorting prior to 
transmission. Thus, these functions will migrate to Orbiting Platforms and no longer need to be supplied 
by the Network. The DIF functions incorporate two classes of functions: those such as routing and 
muxing which can be done in real-time, and those such as storage for outage protection. Real-time 
functions will migrate to the ASDACS/DDSS which will do the necessary on-board processing to route 
data to various ground destinations. However, functions requiring significant or long term storage will 
remain on the ground. But, since the ASDACS/DDSS routes data directly to Major Facilities, these 
functions will be provided at the Major Facilities and will not require system support. F inall y, the fifth 
group of functions such as the processing of instrument data, as well as error encoding/decoding tailored 
to the source data, will stay with Major Facilities from the year 2000 to 2010. However, by 2010 these 
functions will also be done by End Users that receive direct data distribution from die ASDACS/DDSS. 
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Exhibit 3—3: Logical Evolution of the Functional Allocations Within Space Network Elements 
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3.3 ATDRSS HERITAGE 

Exhibit 3-4 summarizes key aspects of ATDRSS heritage showing the baseline space netwoik and 
spacecraft configuration of the ATDRSS era. Note that all space-to-ground connections are via the 
ATDRSS ground terminals (AGTs), and from there, connections to the Major Facilities (POCCs and 
Science Data Centers) and supported via CDOS in concert with NASCOM. 

The spacecraft functional configuration is of significance because it embodies the service types that 
ATDRSS will support on its space-space links to orbiting platforms [12, 13]. The three categories of 
services are as follows: 

• Single Access (SA) Service: Provided via dedicated steerable antennas at S-band, Ku- and Ka-band 
frequencies (tri-frequency feeds). SA service is applicable to high data rate services, or missions 
requiring high EIRP and/or G/T. 

• Multi-Access (MA) Service: Provided via a phased array at S-band. MA service is applicable to 
low and moderate data rate services. 

• Beacon: LEO coverage with a 125 bps channel at S-band. Beacon service is applicable to system 
status messages and short user-directed data packets. 
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BASELINE ATDRSS 

SPARE 




171-W - 174*W 



Ku UPLINK 


Ku/Ka DOWNLINK 


Ku UPLINK 
Ku/Ka DOWNLINK 


INTERFACILITY 




POCCS + 
SCIENCE 
DATA 
CENTERS 


ATDRSS SPACECRAFT-REFERENCE FUNCTIONAL CONFIGURATION 


DOWNLINK (TDRSS COMPATIBLE) 
- Ka, DOWNLINK ONLY (NEW) 


LEO COVERAGE 
BEACON: 


NAVIGATION Jc TIME 
TRANSFER 
SYSTEM ORDER WIRE 
SYSTEM STATUS 



(FSG) 

• ADDITONAL WEIGHT/ 
POWER /SPACE / 
ALLOCATION FOR >7 
FUTURE X/ 

SERVICE X/ 
GROWTH; C< 

E.G., 

- crossunk y 

- MULTI-BEAM 
SCL FOR 

MULTV- SITE N 
DATA DISTRIBUTION 


ENHANCED SMA 


• INCREASED NUMBER 

OF ELEMENTS RELATIVE 
TO TDRSS 

- SMA/SSA GA 
COMPARABILITY 

• ON-BOARD BEAMFORMING 

- 5 CHANNELS, RETURN 

- 2 CHANNELS. FORWARD 

• DATA RATE MAXIMA 

- 3 MBPS, RETURN 

- 10 KBPS, FORWARD 

• REDUCED SPACE-TO-GROUND 
k LINK BANDWDTH 


Exhibit 3-4: ATDRSS Heritage 
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3.4 EVOLUTION OF SERVICE CONCEPTS 

Exhibit 3-5 illustrates the rationale for space-space service evolution from 1996 to 2010, and a probable 
path for such evolution. The key rationale for evolution in the services offered by the ATDRSS is to 
provide a better match between services and applications. For example, TDRSS in 1996 offers essentially 
only a circuit-like service which dedicates a portion of the communications payload for the service 
duration. This is an efficient allocation for applications such as data storage dumps which are continuous 
and of long duration. But for applications such as iteractions with space instruments, the traffic will be 
bursty and not efficiently serviced via a dedicated resource. Thus it is natural for the circuit-like service 
of the TDRSS era to evolve to more dynamic allocations now widely used in modem telecommunications. 

Two popular forms of dynamic allocation are TDMA and packet-switched service. The seeds of both 
service types are already present in current TDRSS and ATDRSS concepts. For example, the TDRSS and 
ATDRSS MA service is provided via an S-band phased array which could be capable of rapid beam- 
steering needed for time division sharing. This is especially valuable for the forward link since in both 
TDRSS and ATDRSS, the forward MA links are fewer in number than the return links. Thus, a 
dynamically allocated forward link could be effectively time-shared among a number of return link users 
in order to support "two-way" services to those users with die time-shared forward link. For packet 
switching service, the LEO coverage beacon concept for the ATDRSS has the capability to support a low 
data rate (< 125 bps) random access channel for short data packets directed to orbiting users. In the 
DDSS world, such a packet service could be provided via a similar beacon or possibly even via packet- 
switched control of the phased array antenna beam. 
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Service Evolution Rationale and Direction 
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Exhibit 3-6 provides further insight into the definition of the three kinds of service envisioned for space 
platforms within ASDACS/DDSS. The three service types are as follows: 

• Dedicated Single Access (DSA) service: This is essentially a circuit service typically reserved by 
schedule. The lead time for service reservation may be as long as a few weeks or as short as a few 
minutes. 

• Dynamic Multiple Access (DMA) service: This is a circuit-like service which can be requested and 
configured with a short lead time of as little as a few seconds. Service reservation will typically 
be handled via a Demand Assigned Multiple Access (DAMA) protocol. 

• Message Transaction (MT) service: This is a packet service which is accessed spontaneously via 
a Random Multiple Access (RMA) protocol. No lead time for service request/configuration is 
needed because the data packet contains the required routing information in its overhead. 
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SECTION 4 

ALTERNATIVE SYSTEM ARCHITECTURES 

In this section, alternative high-level DDSS architectures are defined and evaluated. The key subsystems 
for the architectures are developed and the major subsystem requirements are derived from the overall 
DDSS requirements. 
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4.1 DEFINITION OF ALTERNATIVES 

Exhibit 4-1 illustrates the process the developing the various system architectures for the DDSS concept. 
Starting from the general DDSS concept on the left, the first branch as we move right defines the two 
major classes of alternative architectures. The topmost branch pertains to the class of architectures that 
have a stand-alone Data Distribution Satellite (DDS) separate from the ASDACS. These architectures are 
referred to as the CONUS Gateway architectures because the DDS is placed above CONUS in 
geosynchronous orbit and serves as a communications gateway for all of CONUS. This gateway acts as 
a relay between different ground terminals, and between ground terminals and the ASDACS satellites 
which provide the connectivity to the Orbiting Platforms. The lower branch of architectures are referred 
to as Global Network architectures because these provide a global network that links together all the major 
facilities and end users worldwide. In this class of architectures the ASDACS and DDSS functions are 
integrated into a single spacecraft, and a number of such spacecraft (2-4) are placed around the 
geosynchronous arc, connected via crosslinks, thereby supporting the global network. 

For both classes of architectures, additional branching occurs as we move to the right. These branches 
are distinguished by variations in the number of spacecraft, orbital spacing and other features that define 
the constellation. Finally, for each of these new branches, additional alternatives are distinguished by 
alternative implementations of the ASDACS and DDS communications payloads. 
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Exhibit 4—1: Defining Alternative Architecture 
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Exhibit 4-2 illustrates the variety of alternative constellations for the two classes of architectures. 

For the CONUS Gateway architecture denoted by A, the total ASDACS capability is contained in just two 
satellites. Thus each satellite is assumed to support four dedicated single access (DSA) services which 
are likely to be one of the primary drivers for satellite real estate. For the constellations with four 
satellites (B and C), each ASDACS supports only two DSA services. 

Similarly, in the Global Network A architecture with two satellites, each supports four DSA services. In 
the three satellite constellation, three DSA services are supported by each satellite, and in the four satellite 
constellation, each supports only two DSA services. 
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Exhibit 4—2: Alternative Constellations 
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Exhibit 4-3 summarizes and compares some of the key features of architecture/constellation alternatives 
in various categories. These high level features, together with the subsystem and implementation 
considerations developed in the rest of Section 4 and in Section 5, form the basis for evaluating the 
alternatives. 

Within the CONUS Gateway architectures, option A is attractive because it requires only two system 
crosslinks from a DDS to the ASDACS constellation. Options B and C require four system crosslinks 
from the DDSS to the ASDACS constellation and this is a big driver for DDS real estate. Option A also 
requires fewer ASDACS than B and C, but this is balanced somewhat by the fact that the option A 
ASDACS must support 4 DSA services while the ASDACS of options B and C support only 2. 

Within the Global Network Architectures the capability of Option A to support global networks is limited 
because it has just two satellites in two different orbital slots. Option B is seen to be the most attractive 
of the Global Network Architectures because with 3 satellites in 3 different orbital slots it can support 
networking and data distribution to the U.S. and all its international partners in Space Station Freedom. 
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Exhibit 4—3: Key Features of Architecture/Constellation Alternatives 
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4 2 DEFINITION OF KEY SUBSYSTEMS 

Exhibit 4-4 defines and illustrates the subsystems, interfaces, and data flows for the CONUS Gateway and 
Global Network architectures. In the Gateway architecture, the key subsystems for the ASDACS and DDS 
spacecraft are as follows: 

• ASDACS 

- Space-Space subsystem 

- Crosslink subsystem 


• DDS 

- Crosslink subsystem 

- Processing and Routing subsystem 
— Space-Ground Link subsystem 

In the Global Network architecture, the key subsystems for the combined ASDACS/DDSS spacecraft are 
as follows: 

• ASDACS/DDSS 

- Space-Space subsystem 

- Processing and Routing subsystem 

- Crosslink subsystem 

- Space-Ground Link subsystem 

For both the Gateway and the Global Network architectures, the traffic to and from all subsystems is 
developed from the top-level requirements identified in Section 2. Note that for the Global Netwoik 
architecture, the traffic on most of the links is greater. More significantly, the required connectivities are 
far more complex. This significantly complicates netwoik management and puts a major burden on the 
processing and routing subsystem of the satellites. 
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Exhibit 4-4: DDSS and ASDACS Connectivity and Interfaces 
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Exhibit 4-5 summarizes the allocation of functions to different subsystem. This functional allocation is 
then the driver for defining the detailed subsystem requirements and implementation alternatives in the 
next section. 
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Exhibit 4—5: Functional Allocation to ASDACS/DDSS Subsystems 
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SECTION 5 
SYSTEM DEFINITION 


The entire system that is defined in this section is composed of the following elements: 

• The DDSS communications payload 

• The ASDACS communications payload 

• Orbiting Platform communications payloads 

• Major Facility ground terminals 

• End User VSATs. 

The scope of this definition activity includes high level trades arriving at antenna apertures, EIRPs, and 
frequencies, as well as implementation trades that guide how such front-end requirements can best be met 
for the implementations of all the subsystems of the DDSS and ASDACS. 
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5.1 APPROACH TO SYSTEM DEFINITION 

Exhibit 5-1 outlines the approach to system definition. The requirements, operations concept, and 
architectures, along with the ATDRSS heritage, fonn the basis for system definition. The approach is to 
consider first the DDSS and ASDACS subsystems that have interfaces with the Orbiting Platforms, Major 
Facilities and End Users. Defining these interfaces involves a variety of trades regarding the needed 
system resources versus user resources in closing a link at the required data rate. Thus in the process of 
defining the ASDACS Space-Space subsystem and DDSS SGL subsystem, the communications capabilities 
of the user terminals (Orbiting Platform, Major Facility GT and End User VSAT) are also defined. As 
part of this process, the channel structure of the communications link is also determined and this exerts 
a strong influence on the implementation of the DDSS Processing and Routing subsystem. The channel 
structure includes such areas as access protocols (i.e., DAMA, RMA) multi-user muliplexing (i.e., TDMA, 
FDMA modulation format, and channel coding. With the completion of the trades for the Processing and 
Routing subsystem and the Crosslink subsystem, die entire ASDACS and DDSS communications payload 
is defined along with the user community ground and orbiting terminals. 
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Exhibit 5—1: Approach to System Definition 
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52 THE SPACE-SPACE SUBSYSTEM 

The Space-Space subsystem is assigned to the ASDACS. Its primary function is to serve as the 
communications interface for the Orbiting Platform users. Three basic service types are offered by the 
Space-Space subsystem. These have been described in Section 3. These three service types are as 
follows: 

• Dedicated Single Access (DSA) Service 

• Dynamic Multiple Access (DMA) Service 

• Message Transfer (MT) Service. 

Providing for these services places requirements on both the user and the ASDACS communications 
payloads. Exhibit 5-2 summarizes the results of the trades that define the key parameters of the Orbiting 
Platform user and ASDACS payload. Five different users are listed: one DSA user, three classes of DMA 
users, and one MT user. The results are strongly driven by ATDRSS heritage in matters of user aperture, 
power, and frequency utilization. The need to limit the demands on user aperture and power is a prime 
determining factor, as are operational factors, such as the concept that certain user services (e.g., MT via 
a beacon) at low data rate must not require user antenna pointing, and therefore must be available to users 
with only omm antennas. Exhibit 5-3 illustrates the ASDACS Space-to-Space subsystem reference 
payload configuration that has been defined. 

5.2.1 Dedicated Single Access Service 

The primary driver for the aperture and power for DSA service is the return link. For 650 Mbps service, 
the trade between user and ASDACS resources results in a requirement for a 2 meter antenna and a 10 
watt transmitter for the user, and for ASDACS, a G/T of about 30 dB/K consistent with a 3-5 meter 
antenna aperture and a 1000° K system noise temperature. The forward link EIRP value listed for the 
ASDACS is comparable to that planned for ATDRSS Ka-band service, and this value could support up 
to about 2 Mbps to a DSA user with a 2 meter antenna. Higher data rates than this, such as the 25 Mbps 
envisioned for Space Station Freedom would require a larger user antenna aperture or a greater ASDACS 
EIRP. In the reference configuration of the ASDACS Space-Space subsystem illustrated in Exhibit 5-3, 
the DSA service is provided via dedicated steerable antennas. A key driver for this implementation is the 
combined requirement of high gain and wide steering ability, which makes a multi-beam phased array or 
phased array-fed antenna unsuitable for this application. The number of single access antennas required 
is 2-4, depending upon the chosen ASDACS/DDSS architecture and constellation. 

5.2.2 Dynamic Multiple Access Service 

The DMA service envisioned will support return data rates from below 1 Kbps to 3 Mbps. Exhibit 5-2 
illustrates the required user parameters for three users that cover this range of data rates. For the same 
user set, the range of forward data rates is from 1 Kbps to 100 Kbps. The return link G/T for the 
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Exhibit 5—3: ASDACS Space-to-Space Reference Configuration 
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ASDACS DMA service is assumed to be 9 dB/°K which is the same as is currently planned for ATDRSS 
[12]. The 3 Mbps user needs only a 0.75 meter antenna to make the link with 4 watts of transmit power. 
The 50 Kbps user with the same power requires an antenna with about 8 dB gain which could be provided 
by an Electronically Switched Spherical Array (ESSA) antenna envisioned for midsized space platforms 
[14]. Finally, the 10 Kbps user would require only an omni antenna and 4 watts of power. The forward 
DMA service with the same user population could support 100 Kbps, 10 Kbps and 1 Kbps respectively. 
This service represents an evolution from ATDRSS in that a forward EIRP of 43 dBW is assumed, which 
is a 6 dB increase relative that planned for ATDRSS [12]. Furthermore, the dynamic tim e sharing 
envisioned for this service is a significant evolution from ATDRSS. Since the implementation for the 
DMA service is envisioned as a phased array, it can be capable of rapid steering on the timescale of a 1 
msec or less. Thus, it is possible to timeshare a single forward DMA service among many users. For 
example, several users of a single 10 Kbps beam could each be allocated a 1 sec time slot every 10 
seconds. Each user would therefore be supported by an equivalent 1 Kbps link which would have the feel 
of a continuous contact Thus, in this manner, the imbalance between forward and return MA service in 
ATDRSS could be eliminated in ASDACS. 

5.2.3 Message Transfer Service 

MT service would be provided via a 10° conical beacon at S-band covering all LEO orbits. Such a 
service is currently envisioned as an option for ATDRSS. For ASDACS, we have assumed a 30 dBw 
EIRP which is consistent with about 15 dB gain and less than 30 watts of transmit power. Such a beacon 
could provide a continuous 125 bps service supporting both system messages and short user directed 
messages to all users with only omni gain antennas. A 125 bps service could also be provided on the 
return link. 

53 THE SPACE-GROUND LINK (SGL) TRADES 

Exhibit 5-4 summarizes the results and key drivers for the definition of die SGL subsystems for the DDSS, 
and Major Facility and End User ground terminals. Hie SGL subsystem is composed of the three 
antennas as illustrated in Exhibit 5-5. These are as follows: 

• High gain transmit antenna 

• High gain receive antenna 

• Low gain duplex antenna. 

Together, these antennas support all the SGL subsystem requirements for the DDSS. 

5.3.1 High Gain Transmit Antenna 

The high gain transmit antenna has a nominal 300 Mbps interface with the Major Facility ground terminals 
on both the uplink and downlink. Ka-band is the frequency of choice to accommodate the multi-Gbp>s 
envelope requirement A narrow beam of 0.3° on the downlink is driven by the need to limit the required 
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Exhibit 5-4: Summary Overview of DDSS SGL Subsystem Trades 
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Exhibit 5—5: DDSS SGL Subsystem Reference Configuration 
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satellite power. Each beam is supported by as little as 2 watts of power, but the phased array fed antenna 
can adapt to rain fades and provide an additional 10 dB of power for selected beam dwells. A 5 meter 
antenna aperture is chosen as the baseline for the Major Facility ground terminals. Up to roughly 600 
Mbps could be transmitted to each major facility by assigning two 300 Mbps beams. 

The high gain antenna has a 150 Mbps interface with End User VSATs. This is supported by the same 
transmit beams that serve the Major Facility ground terminals. In order to conserve satellite power, the 
data is assumed to be rate 1/2 coded, and a VSAT antenna size of 2 meters is selected. This is an 
optimum choice because with the coding, the channel bandwidth of the End User data streams are equal 
to those of the 300 Mbps Major Facility data streams. Coding, together with the lower data rate, requires 
about 8 dB less transmit power, but this is exactly compensated for by the lower gain of the VSAT 
antenna. Thus the beams of the high gain antenna system have the same characteristics for both Major 
Facilities and End Users, so that the common system described here can efficiently meet both needs. 

532 High Gain Receive Antenna 

The high gain receive antenna provides a 300 Mbps uplink with the Major Facilities. Because the End 
Users have no need to transmit very large amounts of data, they do not have an interface with the high 
gain receive antenna. Since this system serves only Major Facilities, and since Major Facilities tend to 
be clustered in distinct geographical areas, a relatively simple high gain receive antenna implementation 
can be considered. Ten fixed beams in selected areas could encompass all of NASA’s centers and other 
sites that will contain the archives, processing and other infrastructure for managing space data With their 
5 meter antennas, the Major Facility ground terminals will require only about 10 watts of transmit power 
to support a 300 Mbps data stream into the 0.3° receive beam widths assumed for the DDSS high gain 
receive antenna. Options of operating at 150 Mbps rate 1/2 coded and/or using a 100 watt transmitter will 
provide up to 18 dB of rain margin. 

533 Low Gain Duplex Antenna 

The low gain duplex antenna creates a transmit and receive beam over its entire coverage area, such as 
CONUS. It serves as the receive interface for all End Users. For consistency with VSAT concepts, the 
uplink channels are assumed to be demand assigned FDMA/SCPC, supporting data rates up to 128 Kbps. 
Less than 5 watts of transmit power will provide a large rain margin for 16 Kbps data rates. For higher 
data rates, only a small margin would be provided. 
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5.4 PROCESSING AND ROUTING SUBSYSTEM 

The DDSS processing and routing subsystem has an interface with all the users of the DDSS as illustrated 
in Exhibit 5-6. The choice of the implementation of the processing and routing system is strongly driven 
by the requirements and constraints of its users, including such parameters as envelope data rate, 
modulation format, channel multiplexing and access protocols. The key user interfaces are as follows: 

• Interface with Major Facilities: 300 Mbps on both the uplink and the downlink with TDMA 
allocation of multiple beams 

• Interface with End User VSATs: 150 Mbps hopping beams on the downlink and many (1000s) of 
FDMA/SCPC low data rate channels on the uplink; demand assigned access on both links 

• Interface with Orbiting Platforms: Several channels in forward and return directions with a wide 
range of data rates and formats; mostly dedicated, but some time-shared channels. 

In consideration of alternative switching implementations, it is important to strike the proper balance 
between switching flexibility and complexity that accounts for the requirements and constraints of its users 
while it avoids needless complexity. That is, the switching implementation should provide the needed 
flexibility to its users, while it minimizes overall processing requirements. The following is a list of 
alternative switching implementations for the processing and routing subsystem: 

• Microwave space switch matrix 

• Baseband space switch matrix (w/o memory) 

• Baseband time-space-time switch (w/memory) 

■ Fast packet switching 

• Datagram packet switching. 

For a given throughput, the two top most alternatives embody the least system complexity, but offer the 
least user flexibility. Thus, these are most suitable for switching high data traffic among a few nodes such 
as the Major Facilities. At the opposite end, datagram packet switching offers the most flexibility but it 
is inefficient and not desirable or feasible for high data rate links. Rather, it is most suitable for low data 
rate traffic on the random access channel. 
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Exhibit 5—6: Scope of DDSS Processing Routing Requirements 
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Exhibit 5-7 illustrates the chosen implementation for the DDSS processing and routing system for the 
CONUS Gateway architecture. The key features are as follows: 


• Dynamic Crosspoint Switch: this switch provides high data rate connectivity directly between all 
major facilities. This by far the least complex implementation for switching very high data rate 
streams between a small number of ground terminals. 

• Fast Packet Processor This provides the needed flexibility for switching the 150 Mbps streams 
directed at the End User VSATs. Unlike datagram packet switching which is suited only for short 
messages at low to moderate data rate, fast packet switching protocols require a minimum of 
overhead and can operate at high data rate of 150 Mbps and beyond. 

• Virtual Channel Processors: the forward and return virtual channel processors are essentially fast 
packet switching devices for the Space-Space data channels which we assume to utilize the CCSDS 
data protocols. The return space channel buffers are required to synchronize the returning space 
data to the TDMA timing scheme of the dynamic crosspoint switch. 

• Dynamic Controller: the system illustrated in Exhibit 5-7 requires a controller to ensure that all the 
switching components are configured at the proper timing epochs. 


The processing and routing system for the Global Network architecture is similar, but the crosspoint switch 
is of a higher dimension and it has a direct interface to the crosslink system. 


5-12 


CONUS GATEWAY ARCHITECTURE 


INTERFACE WITH CROSSUNK 



03/15/91 1F91 023\RB7476 


Exhibit 5—7: DDSS Processing and Routing Subsystem 
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5.5 CROSSLINK SUBSYSTEM 

Exhibit 5-8 summarizes the key features of the DDSS crosslink subsystem for the CONUS Gateway and 
Global Network architectures. The parameters for both optical and 60 GHz implementation are included. 
In general, the requirements for the Gateway architecture are considerably less for two reasons: the 
Gateway architecture crosslink supports a lower data rate envelope and it also spans a shorter GEO arc. 
Together, these two factors account for almost a 10 dB difference in required power. For both the 60 GHz 
and optical alternatives, the optimum design is typically to choose the laigest reasonable receive and 
transmit apertures and to size the transmitter power sufficient to complete the link. For optical links, the 
practical maximum aperture chosen is 20 cm and for 60 GHz a 2 meter aperture is chosen. 
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Exhibit 5—8: DDSS Xlink Subsystem Reference Configuration 
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5.6 TOTAL COMMUNICATIONS PAYLOAD 

In this section the features of the communications payloads of the DDSS and ASDACS are summarized. 
5.6.1 Payload of the CONUS Gateway Architecture 

Exhibit 5-9 summarizes the key features of the communications payload for the ASDACS and the DDSS. 
The ASDACS payload is composed of the Space-to-Space subsystem and the Crosslink subsystem. Since 
we have chosen to load all the processing complexity on the DDSS, the ASDACS payload is a simple 
frequency translation repeater. A 60 GHz implementation is chosen since it is most suited to this 
implementation. The DDSS contains the Crosslink subsystem (providing a link to two ASDACS), the 
SGL subsystem and the Processing and Routing subsystem. Exhibit 5-10 illustrates the DDSS payload 
concept and an example satellite configuration. 
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Exhibit 5—9: Communication Payload For CONUS Gateway Architecture 
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Exhibit 5—10: Operational DDSS For CONUS Gateway Architecture 
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5.62 Pavload of the Global Network Architecture 

Exhibit 5-11 summarizes the key features of the communications payload of the combined 
ASDACS/DDSS of the Global Network architecture. This payload is comprised of the Space-to Space, 
Crosslink, SGL and Processing and Routing subsystems. Exhibit 5-12 illustrates a logical diagram of the 
payload as well as a satellite concept. Even at this level it is clear that so many functions are combined 
in the satellite so that its complexity is high. Furthermore, all the real estate requirements for large 
antenna apertures will make the packaging of this satellite a difficult and challenging undertaking. 
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Exhibit 5-11: Communication Payload For Global Network Architecture 
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Exhibit 5-12: Operational ASDCS/DDSS For Global Network Architecture 
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5.7 PAYLOAD MASS AND POWER SUMMARIES 

Exhibits 5-13 and 5-14 summarize the payload mass and power estimation for the CONUS Gateway and 
Global Network architectures, respectively. The estimation methodology is summarized in Section 8. The 
payload of the CONUS Gateway satellite is large, but its mass and power envelopes are comparable to 
payloads of large communications satellites that have been built or envisioned. In particular, the Gateway 
payload mass is comparable to that of INTELSAT VI, and its power is comparable to INTELSAT VII. 
Further, both its power and mass are consistent with the capabilities envisioned for the GE 7000 series 
communications satellite bus. 

In contrast, the payload mass and power of die Global Network architecture are well outside the bounds 
envisioned for even very large communications satellites. Although, a combined ASDACS/DDSS is an 
interesting concept, its development would pose a far greater technology risk than the Gateway satellite. 
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Exhibit 5-13: CONUS Gateway Architecture Communications Payload Mass and Power Estimates 
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Exhibit 5-14: Global Network Architecture Communications Payload Mass and Power Estimates 

Data Base: (15) ATDRSS Phase A studies: (16) ATDRSS Xlink study; (17) ATDRSS MBA study; (18) 
Ball aerospace antenna; (19) GSFC microelectronics branch prototyping of CCSDS processors ; (20) TRW 
bulk demodulation estimates; (21) COMSAT packet switching study 
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SECTION 6 

TRANSITION TO THE DDSS/ASDACS ARCHITECTURE 


According to current ATDRSS plans, the ATDRSS era will commence in 1997 with the first ATDRSS 
launch, and will last for approximately 15 years, or until about the year 2012. This section explores the 
timing and alternatives for a gradual transition from die ATDRSS to the follow-on DDSS/ASDACS 
system. 
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6.1 SYSTEM EVOLUTION 

The transition from the ATDRSS to the CONUS Gateway Architecture involves the major changes in a 
number of areas. These include: 

• Changeover to a new system architecture and orbital constellation 

• The development of new communications payloads and satellites 

• The insertion of new technologies into the communications payloads 

• The introduction of new operations concepts concerning service provision, assurance and scheduling 

The two architectures are illustrated in Exhibits 6-1 and 6-2, respectively. The baseline ATDRSS is 
comprised of four operational satellites which all have line-of-sight to the ATDRSS ground terminals at 
the White Sands complex. In this architecture, all SGL connections to the satellites are via the White 
Sands complex. In contrast, in the CONUS Gateway architecture there are many SGL connections to the 
Major Facilities and thousands of connections to VSATs widely distributed over CONUS. Furthermore, 
neither of the ASDACS satellites have line of sight to White Sands, but are instead connected to White 
Sands and other CONUS locations via crosslinks. 
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Exhibit 6—2: ASDACS and DDS 2010+ — CONUS Gateway 
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With the introduction of so many new features, it will be important to plan the transition so that the new 
features can be demonstrated prior to operations, and these features can be introduced in a gradual manner. 
Exhibit 6-3 illustrates the various time frames concerning the evolution of NASA’s space network from 
TDRSS, through ATDRSS, and finally to the DDSS/ASDACS system. Within this timeline, it is seen that 
the ATDRSS Future Service Growth (FSG) module [12] can play a key role in supporting an orderly 
transition from the ATDRSS to its follow-on (i.e. the DDSS CONUS Gateway architecture). The 
ATDRSS/FSG is a reserved allocation of spacecraft resources (weight, power, size, view angles) that will 
host a payload yet to be defined. The objective of the FSG is to support a modest growth in the services 
offered by ATDRSS. Possible payload options under consideration include a crosslink capability as well 
as a direct data distribution capability. 

In Exhibit 6-3, timelines for three phased activities are shown to play a key role in support a smooth and 
orderly transition from ATDRSS to the CONUS Gateway architecture. These are as follows: 

• Flight demonstrations of new capabilities and services via the ATDRSS/FSG 

• Provision of new operational services via the FSG 

• Launch of a demonstration satellite that will support existing ATDRSS satellites in a new mode to 
demonstrate and provide vastly improved services in concert with ATDRSS 

The opportunities for the first flightt demonstrations utilizing the ATDRSS/FSG will occur from the late 
1990’s to the early 2000’s. If successful, similar payloads on the FSG will support service enhancements 
throughout the ATDRSS era, from die early 2000 ’s to beyond 2010. Finally, starting about 2005, the 
launch of a demonstration satellite with similar capabilities to the DDS in the CONUS Gateway 
architecture would be feasible. Each of these activities are phased such that the preceding activity 
supports die definition of the follow-on. Thus, the POC models activity leads naturally into the detailed 
definition and development of FSG payloads. Similarly, successful demonstration of an FSG capability 
leads to operational support of that capability. This operational capability can then be greatly enhanced 
by the introduction of the demonstration DDS which in conceit with a crosslink to the ATDRSS FSG, can 
close the ATDRSS coverage zone of exclusion and offer direct data distribution services. Finally, the 
demonstration DDS will support a gradual transition to the DDSS/ASDACS climax architecture as is 
shown in Exhibit 6-4. 
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Exhibit 6—3: Timeframes for Evolution from TDRSS to ATDRSS and Beyond 
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Exhibit 6-4 illustrates a potential scenario for demonstration and transition from the ATDRSS to the 
CONUS Gateway architecture. At the top is the baseline TDRSS architecture. In the FSG demonstration 
phase, just below, one of the eastern satellites at 41 deg. West would be moved to 9 deg. and be 
supported via a crosslink to the remaining ATDRSS satellite at 41 West. In this manner, the crosslink 
capability would be demonstrated along with closing the ZOE. Further down, with the introduction of 
the demonstration DDS, a hybrid architecture is established in which two of the satellites are supported 
directly via White Sands as in ATDRSS, and two satellites are supported via the DDS via crosslinks. This 
hybrid architecture provides a gradual transition phase since with a failure of either the DDS or ATDRSS 
baseline, half of the on-orbit service capacity is maintained. 


6-6 




4VW 


41 "W 


BASELINE ATDRSS 
ARCHITECTURE 


& 


• ATDRSS /FSG DEMO 

• EVOLUTION TO OPS 

• SHORT X-LINK SUPPORTED 
BY FSG CLOSES ZOE 

• LONGER X-UNK VALIDATES 
DEMONSTRATION DDS 


171*W 


1 




• TRANSITION ARCHITECTURE 

• DEMONSTRATION DDS DOES 
ON-BOARD PROCESSING AND 
PACKET SWITCHED DIRECT 
DISTRIBUTION OF DATA 

• X-LINKS TO DDS SUPPORTED 
BY FSG CLOSES ZOE 

• ALSO SUPPORTS NETWORKING 
AMONG MAJOR FACILITIES 


0 ATDRSS 
O ASDACS 
■ DDS 

(DEMONSTRATION) 
DDS (OPERATIONAL) 


ASDACS 


IP 
I W 


ASDACS 


• ASDACS HAS 2 4 SA CAPACITY 
AND X-UNKS TO DDS 

• OPERATIONAL DDS DOES 
DIRECT DISTRIBUTION AND HAS 
INCREASED CAPACITY OVER 
DEMO DDSS 

• DDS ALSO SUPPORTS 
SUBSTANTIAL NETWORKING 
LOAD AMONG MAJOR FACILITIES 
AND END USERS 


AGT EVOLUTION 


03/15/91 TF91 023\RB7477 


Exhibit 6—4: Potential Route for ATDRSS/FSG Evolution to ASDACS/FSG 

Conus Gateway Architecture 
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SECTION 7 

DEMONSTRATIONS AND PROOF-OF-CONCEPT MODELS 


In this section, the key demonstrations and proof-of-concept (POQ models that support the development 
of the DDSS are identified and discussed. 
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7.1 OVERVIEW 


Exhibit 7-1 summarizes four activities that arc important for demonstrating the functionality and 
performance of key DDSS requirements. Each activity embodies a demonstration and an associated POC 
model development. The four activities are as follows: 


• Demonstration of Dynamic Multi -Access (DMA) Service: The ATDRSS SMA array is used to 
demonstrate rapid beam steering and timed-shared use of a single SMA transmit beam by two or 
more Orbiting Platforms. 

• On-orbit Demodulation of Space-Space Channels: The ATDRSS/FSG is used to host a payload that 
can demodulate all varieties of envisioned ATDRSS SMA services. 

• ATDRS-ATDRS Crosslink: The FSG on two ATDRS are used to support an optical intersatellite 
connection supporting a data rate of 300 Mbps or more. 

• Extraction and routing of CCSDS virtual channel data units (VCDUs): The FSG on an ATDRS is 
used to process a CCSDS data stream and extract at least two distinct VCDUs. 

Each of these four activities is discussed below in greater detail. In addition, a payload with the combined 
capability of on-board demodulation, VCDU routing, and an optical communications terminal will have 
all the elements to demonstrate direct distribution of space data to selected locations. 


7-2 




'-3 


Exhibit 7-1: Key Demonstrations and POC Models 
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7 2 DMA FORWARD SERVICE DEMONSTRATION 

Exhibit 7-1 illustrates a demonstration of multiple users sharing a single forward link beam of the SMA 
service of ATDRSS. This demonstration emulates the timeshared forward link DMA service defined in 
this study for the ASDACS. In order to carry out this demonstration, the following elements are required: 

• The ATDRSS enhanced SMA array must be capable of rapid beam reconfiguration; a 1 msec 
reconfiguration time is a reasonable goal that can easily be met by current phased array 
implementations. 

• The communications receiver of the Orbiting Platform must be capable of rapid signal acquisition; 
a 1 msec acquisition time of a forward beam can be easily accomplished if the receiver is already 
tracking the broadcast beacon which is coherently related to the forward beam. 

If a 10 Kbps forward link is assumed, a tenth of a second dwell on a platform could transmit 1000 bits 
of data. If such a dwell is initiated every second, a 1000 Kbps link is established that is virtually 
continuous. Of course, to achieve this with a minimum of overhead, the forward beam must be rapidly 
configured, and the Orbiting Platform must rapidly acquire the frequency, phase, and bit timing of the 
signal. With such rapid reconfiguration and acquisition of the forward link beam, it can be effectively and 
efficiently shared. 

Exhibit 7-1 outlines the concept and time sequence of events for the demonstration: 


• The POCC, the ground controller for the Orbiting Platform, would spontaneously send blocks of 
messages and data spontaneous to the ATDRSS ground terminal (AGT). 

• The AGT would buffer this incoming traffic and route this data stream to the channel of the SMA 
forward beam. The AGT would also control the SMA antenna beamforming to ensure that the 
beam is aimed at the correct Orbiting Platform. 

• The Orbiting Platform user would always be in a beacon tracking mode and in a listening mode for 
a forward signal. Thus if the forward signal characteristics are coherently related to the beacon, the 
user can rapidly acquire the forward SMA beam. 
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DMA Forward Service Demonstration Via ATDRSS 
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A key element of this demonstration is the development of a rapid acquisition user receiver. For the 
ATDRSS signal, the following conditions must be achieved for signal acquisition: 

• Recovering and tracking PN spreading on both the I channel (short coded) and the Q channel Gong 
code). 

• Recovering frequency and phase of the RF carrier. 

• Recovering the bit timing of the data stream. 

Exhibit 7-3 illustrates a candidate architecture for a user POC receiver capable of such rapid acquisition 
of the ATDRSS SMA signal. The architecture is similar to that of the TDRSS Second Generation User 
Transponder built by Motorola [22], and to the TDRSS Balloon Transponder [23] and CCD Integrated 
Receiver [24], built by Stanford Telecom. In the POC receiver, the incoming signal at IF is divided into 
three paths, x, y and z. The x path is dedicated to the reception of the data channel G) of the beacon 
signal: its PN correlator is matched to the beacon and in an ongoing manner, it performs PN code 
tracking, carrier tracking and data demodulation. The y path is dedicated to the range channel (Q) of the 
beacon. Its PN correlator is matched to the beacon range code. Together, the two beacon channels provide 
precise frequency and timing information to the user receivers. The z channel is dedicated to the reception 
of the SMA signal. On all three paths (x, y, and z) a frequency control word (FCW) input to the 
numerically controlled oscillator (NCO) determines the downmixing frequency. Since the beacon and the 
forward signal are coherent, the FCW of the forward link channel is simply a scaled version of the beacon 
FCW that adjusts for any frequency offset between the beacon and die forward SMA service beam. Thus, 
if the x and y channels are already tracking the beacon signal, the acquisition of the forward signal on the 
z channel can be very rapid since it starts from a state where all the signal characteristics except carrier 
phase are established by the x and y paths dedicated to the beacon. 
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Exhibit 7—3: Candidate POC Model for Burst Receiver 
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73 ON-ORBIT DEMODULATION OF SPACE-SPACE CHANNELS 

One of the prerequisites of the direct distribution of space data is on-board demodulation of the return link 
user channels. This is so because, typically, a data stream originating at a single source (i.e. Orbiting 
Platform), will contain many kinds of data sets with a different end destinations. Thus, if direct 
distribution of space data is to be implemented, die data streams from the Orbiting Platforms must be 
demodulated. Only in this way, can the data sets be read and routed in accordance with the information 
embedded in their headers. 

The current TDRSS, and the planned ATDRSS offer a flexible range of communications services to 
Orbiting Platforms including a continuous and wide range and data rates, and a wide variety of signal 
formats. In the initial TDRSS ground terminal at White Sands, NM, several distinct bit syncs and data 
demodulators were incorporated to support this variety. For an on-board demodulation implementation, 
it is clear that it will be important to build a flexible demodulator that can process the variety of data rates 
and formats that exists in the user community. The SMA return service in ATDRSS will likely support 
data rates from 100 bps to 3 Mbps and so a POC model demodulator that could handle this range of data 
rates and all applicable formats would be particularly valuable and relevant Stanford Telecom has 
extensive experience in applying charge coupled device (CCD) technology to flexible demodulators. In 
fact, the output of a current project being done for NASA/GSFC is a single receiver implementation that 
can support all TDRSS return service modes below 10 Mbps [24]. Some of tire highlights of this receiver 
include the following: 

• CCD PN matched filter for fast parallel processing to achieve rapid PN phase acquisition 

• FFT-based carrier acquisition 

• Integrated tracking loop combining PN, carrier and bit sync tracking 

• Programmable gate array (Xilinx) implementation of several receiver modules 

• Advanced 2nd generation TI DSP chips for embedded microprocessors 

Exhibit 7-4 illustrates die CCD integrated receiver demonstration hardware of the current project, and how 
it might evolve to satisfy requirements of a programmable on-board demodulator. The current CCD 
receiver embodies essentially all the functionality required of the POC model, but it is too large for this 
application: a single receiver has card count of 1 1. However, the general approach and algorithms of the 
current CCD receiver are applicable to the on-board application, and with die utilization of technology that 
will be available before 1995, it seems feasible to build a CCD based programmable receiver, with all the 
functionality required, utilizing only one digital card and one analog card. 
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7.4 ATDRSS CROSSLINK DEMONSTRATION 

The key elements of an ATDRSS crosslink demonstration are the ATDRSS/F5G for hosting the crosslink 
payload, and a crosslink payload that fits within the envelope envisioned for the FSG. 

The current concept for the FSG incorporates the following envelope specifications: 

• Maximum mass: 240 lbs. 

• Maximum power & thermal: 260 watts. 

• Maximum volume: 1 1 fit 3 . 

• Field of view: +- 77.5° E-W, +-31.0° N-S 

• Interfaces with TT&C, frequency reference, RF signal, SGL downlink, electrical, thermal and 
structure. 

Since the competition for real estate on the ATDRS is likely to be great, we have favored an optical 
implementation because it requires at most a 20 cm aperture. Furthermore, the technology of laser diode 
power sources is maturing rapidly so that reliable power of the magnitude required will be readily 
available. Some of the key features of the optical crosslink payload are as follows: 

• A 20 cm telescope, two axis gimbaled. 

• About 100 mw of laser power per transmit channel, depending upon the GEO arc spanned. 

• Three transmit and three receive channels. 

• Two of the channels in each direction are digital high data rate channels matched to the ATDRSS 
highest data rate service and selected lower harmonics. 

• One channel in each direction is a lower data rate analog waveform channel. This channel provides 
the flexibility of sending a number of low and moderate data rate services over a single rhannp.i 
while avoiding the need to demodulate the user channels. In this scheme, the RF waveform (that 
is a frequency division multiplex of the multiple channels) intensity modulates the laser transmitter. 

Exhibit 7-5 illustrates the contents of the optical crosslink payload in logical schematic and 7-6 is a 
pictorial representation of the payload. A similar payload is being developed at this time by NASA/GSFC 
for their optical Flight System Development and Demonstration (FSDD) program [25]. 


7-10 




Exhibit 7—5: Optical Crosslink Payload For FSG 



Exhibit 7—6: Pictoral Representation of The FSG Optical Crosslink Terminal 
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Exhibit 7-7 provides some of the key subsystem requirements as well as a breakdown of mass and power 
estimates by subsystem. The buses for these estimates include the FSDD [25], as well as a crosslink study 
just completed by Stanford Telecom for NASA/LcRC [26]. The crosslink payload described here is multi- 
purpose in that it can support a variety of demonstration activities. The most obvious one is a crosslink 
between two ATDRS. As discussed in Section 6, a short crosslink of only about 30° of GEO arc can close 
the TDRSS zone of exclusion. Some time later, this optical payload on the FSG can support the ATDRS 
interface with the demonstration DDSS in an early demonstration of the CONUS Gateway architecture. 
Here the crosslink would span about 80° of GEO arc. 

Note that the estimated mass and power estimates are easily accommodated by FSG envelopes, thereby 
allowing the possible incorporation of onboard processing (demodulation - packet switching) into the 
optical terminal. 
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COMPONENT 

DESCRIPTION 

WEIGHT 

(LB) 

POWER 

(W) 

Telescope 

• 20 cm Diameter 

• A/1 0 Optics 

16 

- 

Gimbal and 
Drive 

— 

33 

40 

Optical Bench 

• < 1 prad Alignment Bias 

• A/30 Optics 

40 

25 

ACQ/TRK 

Subsystem 

• Sub prad Tracking 

• 500 Hz Servo BW 

5 

30 

Laser 

Xmitters (3) 

• 1 Diode per Channel 

• 1 00 mW Per Diode 

• A.-DIV Channel MUX 

15 

15 

Laser Drivers/ 
Modulators (3) 

• Peak Current > 100 mA 

18 

15 

APD/Preamps (3) 

• Gain = 300 

• Low Noise 

• X-DIV Channel Demux 

21 

21 

Demodulators (2) 

• Low Implementation Loss 

12 

10 

Total 

- 

160 

156 


Exhibit 7-7: Description of Optical Crosslink Payload 
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7 S EXTRACTION OF CCSDS VCDUs 

In this section, the CCSDS packet processor for extraction and routing of virtual channels is discussed. 
Exhibit 7-8 illustrates a block diagram of an example CCSDS packet processor (developed by 
NASA/GSFC [19]) along with a list of component functions. For simplicity a limited processor is shown 
with two input data steams and two output data streams. The processing order of each input data stream 
is a follows: 

• Frame synchronization. 

• Reed-Solomon (RS) channel decoding. 

• Virtual channel sorting. 

The virtual channel sorting process divides the input stream into its component virtual channels. In the 
illustrated example, the sorters break up the input channels into two virtual channels. The virtual channel 
outputs are then routed to the virtual channel multiplexer. The virtual channel multiplexers combine the 
input virtual channel into a single output data stream. The resulting two output data streams may then be 
routed to different ground destinations. 
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Exhibit 7—8: CCSDS Data Distrbution Payload Description 
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1.6 DIRECT DISTRIBUTION OF SPACE DATA VIA THE ATDRSS/FSG 

If a space-space Orbiting Platform return link channel is to be flexibly routed in support of direct 
distribution of space data, the following elements must be in place on the ATDRSS/FSG: 

• On-board demodulation of the channel. 

• Multiple SGLs (to different locations). 

• Packet processing capability to break up a CCSDS composite channel into its constituent virtual 
channels. 

The POC model to accomplish the first item was discussed in Section 7.3. The optical terminal POC 
model, discussed in Section 7.4, can route data directly to an optical ground terminal with a cloud free 
line of sight. Finally, a CCSDS VCDU packet processor was discussed in Section 7.5. An FSG payload 
with all three can dramatically demonstrate direct distribution of space data as illustrated in Exhibit 7-9. 
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Exhibit 7—9: Demonstration of Direct Distribution of Space Data 
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SECTION 8 

THE DEMONSTRATION DDS 


This section describes the function and design of the demonstration Data Distribution Satellite in greater 
detail, and develops spacecraft mass, power and cost estimates. 
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8.1 CAPABILITIES 

The primary rationale for the demonstration Data Distribution Satellite is to support the smooth transition 
to the climax CONUS Gateway architecture in the ATDRSS timeframe. With the proper payload on the 
ATDRSS/FSG to support the interface with the DDS, all the key operational capabilities of the climax 
CONUS Gateway architecture can be demonstrated and instituted in the ATDRSS timeframe. These 
capabilities include: 

• Direct distribution of space data to Major Facilities and End User VSATs. 

• Interactive operations of space payloads from VSATs. 

• Wideband networking among all major facilities. 

• Wideband access to Major Facilities from VSATs for data retrieval and supercomputer access. 

Exhibit 8-1 summarizes the key drivers of the demonstration DDS payload and illustrates the various 
payload components. The envelope capacity for space data distribution is roughly 1.2 Gbps which is large 
enough to support at least one ultra-high data rate channel from each ATDRS. In addition, a networking 
capacity of up to 2 Gbps between Major Facilities is provided. The subsystems of the proposed 
demonstration DDS are follows: 

• The SGL Subsystem: this contains a high gain transmitter, a high gain receiver, and a CONUS 
coverage receiver/transmitter. 

— The high gain transmitter implementation is a Ka-band phased array feed antenna with 8 
hopping 0.3° beams that can scan all of CONUS. The power of each beam is between 2 and 
20 watts, adaptive to rain degradation. The data rate supported by each beam is 300 Mbps 
to Major Facilities and 150 Mbps (rate 1/2 coded) to End User VSATs. Higher data rates 
to major facilities are supported via assignment of multiple beams. 

- The high gain receiver is also at Ka-band and supports ten fixed 0.3° beams distributed over 
CONUS so as to provide coverage to all Major Facilities. Each beam supports 300 Mbps. 

- The CONUS receiverNtransmitter provides a shaped duplex beam at Ku-band covering all of 
CONUS. The transmit end supports a 1 Mbps TDM downlink for space data, and the receive 
end supports one or more 100 Kbps uplink random access channels. 

• The Processing and Routing Subsystem: this includes a CCSDS processing capability for space data, 
and additional processing capability for the switching and routing of networking data. 

• The Crosslink Subsystem: this includes the modems and codec for die ATDRSS space-space 
channels, and the two optical terminals that support the links to the two ATDRS. 
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DEMONSTRATION DPS COMMUNICATIONS PAYLOAD DRIVERS 

• Constraints: must be compatible with the crosslink interface of the ATDRSS/FSG - assume optical crosslink interface 

• Objectives: validate and support ATDRSS transition/evolution toward the CONUS Gateway architecture 

• Applicable timeframe: 2005 or shortly thereafter 

• Target requirements: 

- Direct distribution of return space data 

♦ - 12 GBPS total capacity to Major Facilities 

♦ 2 , 1 MBPS total capacity to End Users 

♦ on-board CCSDS packet processing & switching 

- Direct link for forward space data 


♦ - 100 MBPS capacity from Major Facilities 

♦ ~ 100 KBPS capacity from End Users 

♦ CCSDS packet processing & switching 

- Two crosslinks (up to 80° Geo arc) with ATDRSS/FSG 

♦ ~ 600 MBPS receive data rate 

♦ 100 MBPS transmit data rale 

♦ On-board modems/codecs for space-space channels 

- Networking of ground elements (e.g., Supercomputer highway) 

a ~ 2 GBPS total capacity between Major Facilities (300 MBPS links) 

♦ 150 MBPS links from Major Facilities to selected End Users. 


' • 20 CM TELESCOPE 

J • OPTICAL BENCH 

y • LASER XMTR 
I • OPTICAL RCVR 

[XUNK ^BSYSTEM_ 


HIGH GAIN RECEIVER 

• MULTI— BEAM ANTENNA 

- SINGLE FEED/BEAM 

- 0.3* BEAMWDTH 

- FIXED COVERAGE 
OF ALL MFa 

• 300 Mbps INTERFACE 


MODEMS/CODECS 
FOR SPACE— SPACE 
CHANNELS 



•20 CM TELESCOPE 

• OPTICAL BENCH 

• LASER XMTR I 
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SQL PROCESSING 
AND ROUTING 



PROCESSING | 
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ROUTING I 
SUBSYSTEM | 
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IBSYSTEM 




• SHAPED RCV/XMIT 
BEAMS 

•Ku BAND 

• RECEIVE HTERFACE 

- RMA PACKETS 

• TRANSMIT INTERFACE 

- 1 Mbps TDM 
BROADCAST 


HIGH GAIN TRANSMITTER 
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- 2-20 W POWER 
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Exhibit 8-1: Demonstration DDS Communications Payload Drivers 
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8.2 PAYLOAD DESCRIPTION 

Exhibit 8-2 contains a detailed payload diagram of the demonstration DDS. The major components are 
as follows: 

• High gain receiver 30 GHz 

- Multibeam antenna: 10 fixed beams @ 0.3°; 2.7 M diameter main reflector 

- 10 LNAs/DCs 

- 10 demod/decoders: 300 Mbps OR 150 Mbps (W/rate 1/2 coding option). 

• High gain transmitter 20 GHz 

- Multibeam antenna: 8 hopping beams @ 0.3°, 4 M diameter main reflector 

- Phased array feed radiator panel: 4 x 512 radiating elements 

- Active beamforming matrix 

- 8 modulator/encoders 

- 8 UCs/Preamps. 

• Conus coverage Duplex transmitter/receiver Ku-band 

- Conus XMIT/RCV antenna 

- Input frequency demux and down converter 

— Demodulator/decoders for the 100 Kbps RMA uplink channel s 

- 1 modulator/encoder = 1 Mbps 

- 1 UC/HPA. 

■ Processing and routing subsystem 

- Packet processor/statistical multiplexer 

- Forward link virtual channel processor 

- Return link virtual channel processor 

- Dynamic crosspoint switch 

- Dynamic controller. 

■ Crosslink system 

- Frequency Mux/Demus and Modems/Codecs for space-space channels 

- 2 optical terminals: 20 cm apertures 

♦ 20 cm Gimbaled telescope 

♦ 3 APD/Preamps 

♦ 2 QPPM decoders 

♦ 1 100 mW laser. 
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Exhibit 8-2: Detailed Payload Diagram of Demonstration DDS 03/22/91 1*91023x1*7529 
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Exhibit 8-3: Methodology for P/L and Spacecraft Size. Weight and Power Estimation 
8.3 PAYLOAD/SPACECRAFT MASS AND POWER ESTIMATES AND LAUNCH SCENARIO 

Exhibit 8-3 illustrates the mehtodology for payload and spacecraft mass and power estimation used in this 
study. The table in Exhibit 8-4 summarizes the mass and power estimates for the communications payload 
of the demonstration DDS. The estimates were developed from the block diagram payload description 
in Exhibit 8-2. The sources of the data base used to generate the estimates (included in the table) 
encompass numerous payload studies for ATDRSS and several other studies of advanced communications 
payloads. The bottom line payload figures of 980 lbs. and 1669 watts are well within the envelope of 
currently considered payloads for communications satellites 

Exhibit 8-5 summarizes the satellite bus and launch alternatives for a payload of this size. In the GE 
series, the two bus choices are the 4000 and 5000. As indicated, the 4000 series bus is likely to be too 
small to support the DDS payload. The 5000 series bus can probably support a total mass of somewhat 
more than 6000 lbs. at liftoff and a total power of 3 KW at end of life. The mass envelope is roughly 
consistent with the following mass requirements for the spacecraft, stationkeeping fuel, and apogee kick 
motor (AKM): 

• Spacecraft dry weight: 2584 lbs 

• Stationkeeping fuel (10 years): 600 lbs 

• AKM (partially loaded Thiokol Star 488-17): 3200 lbs 

Thus the total weight estimate at liftoff is about 6500 lbs. This is clearly compatible with either an Atlas 
IIAS/Centaur launch or a Titan III launch. It is worth noting that it only slightly exceeds the launch 
capability for an Atlas IIA/Centaur. 


8-6 




SYSTEM ELEMENTS 

WEIGHT (LBS) 

■ 

BASIS OF 
ESTIMATE 

HIGH GAIN RCV SGL 

180 

125 


HIGH GAIN XMIT SGL 

272 

738 


DUPLEX CONUS SGL 

50 

126 

wuam&m 

SWITCHING AND ROUTING 

80 

360 

wmmm 

CROSSLINK TERMINALS 


msMmm 

wum&w 

PROCESSING OF SPACE- 
SPACE CHANNELS 

112 

140 


TOTAL 

980 

(W / C* 10% REDUNDANCY ALLOWANCE) 

1669 




18. BALL AEROSPACE ANTENNA DEFINITION 

15. ATDRSS PHASE A STUDIES 

16. ATDRSS XLINK STUDY 
25. GSFC OPTICAL FSDD 

19. GSFC PROTOTYPING OF CCSDS PROCESSORS 

20. TRW BULK DEMODULATION ESTIMATES 

21. COMSAT PACKET SWITCHING STUDY 


Exhibit 8—4: Summary Mass/Power Estimates for Demonstration 

DDS Payload 



• ATLAS IIA/CENTAUR 
(6200 LB) 


Exhibit 8—5: DDS Bus and Launch Alternatives 05/21/91 ™ 91023 \ RB7731 
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8.4 SYSTEM ARCHITECTURE INCORPORATING A DEMONSTRATION DDS 

As discussed in Section 6, the demonstration DDS, in conjunction with ATDRSS constitute an interesting 
hybrid architecture in which one pair of ATDRS stationed at 41° and 171° West are supported directly via 
White Sands and a second pair are supported via the DDS. Exhibit 8-5 illustrates the segment of the 
system supported by the DDS. The system architecture and operations of the other two ATDRS are 
unchanged from the ATDRSS baseline. The DDS-supported ATDRS are provided flexible high data rate 
connectivity to many Major Facilities, and a 1 Mbps broadcast capability to 1000s of End User VSATs. 
Exhibit 8-5 also illustrates an artists concept of the DDS which clearly shows the transmit and receive 
multi-beam antennas, the optical crosslink terminals, and the CONUS coverage antenna. 
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Exhibit 8—6: Demonstration DDS and System Architecture 
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8.5 COST ESTIMATES OF THE DEMONSTRATION DDS 

Exhibit 8-6 summarizes the cost estimates for the demonstration DDS. The payload and spacecraft bus 
costs were generated using the USCM6 cost model. The outputs are in 1986 dollars. The launch cost 
cited is based upon 1990 data and is in 1990 dollars. As expected, the cost of any new one-of-a-kind 
spacecraft is considerable. However, over half of the cost is attributed to non-recurring payload costs. 
If a significant technology development program is mounted throughout the 90’s in support of DDS-like 
payload capabilities, the actual non-recuning cost is expected to be much less. Furthermore, any DDS 
program purchasing multiple copies will reap the significant unit cost reduction by spreading the 
non-recurring costs over the spacecraft copies. Learning curve phenomena will also promote cost 
reduction. The unit costs for 2 spacecraft and 10 spacecraft are tabulated in Exhibit 8-4 and are believed 
to represent reasonable upper and lower unit cost bounds. In summation, the cost of a demonstration DDS 
is expected to be in the range of 250 million to 500 million dollars. 
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USCM6 COST MODEL (86$) 


COST FOR BUY OF 1 S/C 



LAUNCH** 


NON-RECURRING 


670 M$ 

(- 80% P/L) 
(- 20% BUS) 


RECURRING* 


240 M$ 

(- 70% P/L) 
(- 30% BUS) 


- 100 M$ 


TOTAL 


910 M$ 


- 100 M$ 


SOME SUBSTANTIAL AMOUNT OF NON-RECURRING COSTS MAY BE SUBSIDIZED BY A 
FOCUSSED TECHNOLOGY DEVELOPMENT PROGRAM 


A LARGE S/C BUY WILL SUBSTANTIALLY REDUCE S/C UNIT COSTS 


LOWER BOUND UNIT COST: 254.8 M$ 


- 10 S/C BUY 


- 80% LEARNING CURVE 


UPPER BOUND UNIT COST: 530.6 M$ 


- -2 S/C BUY 


- 80% LEARNING CURVE 
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